Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Communications/Information/high-speed-modem-musings-11.txt

Internet Message Format | 1994-06-11 | 15KB

Date: Thu, 24 Mar 94 08:45:06 EST
From: [e-mail] ( Daniel J. Hofferth   [phone]/Allison Engine Company)
Subject: [*] High Speed Modem Musings (v1.1)


High Speed Modem Musings (version 1.1)

Hi all,

I've now spent a number of months with a new V.32bis (14.4K) FAX/modem that
gave me a variety of little fits until I finally got everything running
just right.  Upgrading from a 2400 baud modem, I found I was mentally
unprepared for the many complications introduced by the much higher speeds.
The new modems are NOT always plug-n-play replacements for older models.

While quietly researching solutions, I noticed quite a few postings in
different lists/digests (such as this one) from people who are suffering
from problems similar to those I puzzled over.  In the hope of helping
someone else, I posted the problems I had and solutions that worked for me.
Since that first posting in mid-January of '94, I've received a surprising
amount of feedback from others who shared my plight, those who still had
questions, and many offering alternative solutions.  This posting comprises
the original file with all of that feedback folded in.  Thanks to you all!

Think these are FAQ's?  Maybe so, but I couldn't find answers in any one
place.  Interesting thing is, these seem like perfectly natural problems
waiting for unsuspecting "slow" modem users who are about to move up.

 <As before, I'll say up front that I am no expert!  I am a neophyte.
  Although I've been a professional computer nerd for many years, I
  know almost zip about high speed modems (as I shamelessly prove below).
  Please feel free to comment, clarify, etc...>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Before I begin, I had a number of people asking if there was any penalty in
performance for using a modem originally sold for a PC on a Mac.  As far as
I know, aside from packaging, bundled software, and supplied cable, there
is NO difference between a modem sold for a PC and one sold for a Mac.

All problems posted below are related to high-speed (HS) communications,
and they occurred while using both CTB and non-CTB applications (Apple's
Communications Tool Box):

1) Trouble establishing a connection.

   I had my modem attached to the wall jack via a long (50 feet) ribbon
   style phone cable... the kind where the wires run parallel to each-
   other in a semi-clear casing <what's the official name?>.  To make
   matters worse, it ran in long straight lengths (around an intermediate
   room), and then into a tangle of power cords for the computer.

   It was a great antenna, but a lousy HS modem extension.  It worked just
   fine for the 2400 baud modem, mind you.  Went to Radio Shack and picked
   up "twisted pair" phone cable (cheap).  Then rerouted it away from the
   power cords.  Bingo - connections made.

   I understand there is also a "high-twist" wire available for data- grade
   communications.  What I bought worked fine for me... my house uses the
   standard twist in the walls... I didn't see any sense in going to data
   grade for just this one length.  They also sell line filters to weed out
   noise - didn't need that either.


2) I could now connect at HS with error correction and flow control, and
   work the user-interface without apparent trouble, but file transfers
   kept causing my modem to hang-up abruptly.

   The Mac's serial port issues the hardware-handshaking (HH) signal on a
   pin that HH-cables also carry to DTR on the modem.  My modem was set to
   hang-up on loss of DTR (AT &D2), when it should have been told to ignore
   DTR (AT &D0).  No more unexpected hang-ups.  For the older modem, this
   was not an issue - it used Xon/Xoff handshaking.

   I've seen postings indicating that some Macs are fast enough to keep up
   with the incoming data flow, no matter how fast it comes in.  For these,
   the messages say, "hang-up on DTR loss" is O.K.  since the Mac will
   never need to use it for flow control.  I'm not lucky enough to own such
   a speed daemon, but this sure sounds like dangerous advice to me....
   What happens when the user pulls down a menu, in mid-file-transfer, and
   lingers there a while deciding what menu item to select?  What happens
   when you're downloading in the background and you launch a BIG program
   from the finder?  Can _nothing_ distract a "fast Mac" long enough to
   force a drop in DTR?  I wonder.  There _are_ other ways to hang-up the
   modem, why tempt fate?


3) No more hang-ups, but high speed uploads and downloads were full of
   packet-errors.  Effective throughput was only about 700-800 cps.

   I knew that I had a HH-cable, software that had HH support enabled, and
   a modem-to-modem connection that was error correcting and flow
   controlled.  But I was still getting sporadic packet errors on file
   transfers.  Clearly HH wasn't working.

   I got out my multi-meter and tested the cable supplied by the modem
   manufacturer.  It WAS a HH-cable, but not wired as suggested by Apple...
   I'm no EE, but it seemed worth swapping out to me.  At my local computer
   store I bought another HH-cable (after being assured that I could return
   it if it didn't work), brought it home and tested it with the meter.
   This one was almost identical to Apple's version except that pin-7 (GPi)
   on the Mac side wasn't connected.  As I gather from other readings, GPi
   is a special purpose pin that isn't used by simple home connectors like
   me.  I tried the new cable, and file transfers were MUCH cleaner, but
   still not perfect.

   <Clearly not all HH-cables are appropriate for all machines.  Just
    because your modem manufacturer supplied a cable for you, don't
    assume it is correct for your Mac.  BTW, there are a few Macs that
    don't support HH... the Plus, LC, and Classic, I beleive... and,
    yes, the LC II and Classic II are O.K.>

   Here is the HH cable recommended by Apple:

                      Mac                 Modem
                      DIN-8               DB-25

                      1  HSKo  ------+--  RTS   4
                                     `--  DTR  20

                      2  HSKi  ---------  CTS   5
                      3  TxD-  ---------  TxD   2

                      4  GND   --+------  GND   7
                      8  RxD+  --'

                      5  RxD-  ---------  RxD   3
                      6  TxD+  (nc)
                      7  GPi   ---------  DCD   8

                      Shield   ---------  Shield

   (Again, remember that the GPi-DCD connection is NOT considered
   essential for normal home connections.  BBS host software only?)


4) File transfers still suffered from packet errors if I switched to
   another application, or simply held the mouse button down on a menu.
   Otherwise, they were going O.K.  What now?!

   Apple claims the priorities for a variety of system related tasks can
   cause the Mac to miss incoming information.  They suggest the following
   guidelines for improving the CPU's attention to the serial port:

      - Limit your Mac-to-modem connection to 19.2KB.

        While the new modems can theoretically achieve throughput of up to
        56KB, this is almost NEVER really achieved.  Text file transfers
        can reach 3500 cps (or so), but most file transfering that we do is
        of already compressed files.  Throughput for these is much closer
        to the modem-to-modem implied speed of 1440 cps.  Thus, 19.2KB is
        fast enough for general use.  38.4KB may be safe if you Mac is fast
        enough (mine isn't).

      - Don't use 24-bit mode, stick to 32-bit addressing.

        24-bit addressing mode apparently peppers the CPU with extra
        interrupts that clouds its ability to watch over the serial port
        flow control... possibly resulting in missed characters.

      - Don't use virtual memory.

        Same reasoning as above.  The overhead required to manage the
        virtual memory impairs the systems ability to keep up with the
        flood of serial port data.

      - Turn off AppleShare.

        Again, same reasoning as above.  AppleShare achieves a higher baud
        rate through its serial port by commanding a higher priority level.

    I was already at 19.2KB between my Mac and modem (having already
    learned that 38.4KB greatly increased my problems), but I was still in
    24-bit mode with virtual memory on.  I've been pretty religious about
    collecting only 32-bit clean software, and I've got enough real RAM to
    turn VM off without problems, so following these guidelines was
    painless for me.

    And they worked.

I now have rock-solid high speed connections on a slow Mac, and file
transfers that are robust enough to let me switch between applications
without packet errors.

What speeds can be expected?

    File transfer speeds, on a full speed (14.4K) connection, HH, with
    hardware compression, etc.  are about 1600 cps when downloading ALREADY
    COMPRESSED files.  I emphasize the "already compressed" part because
    speeds can vary wildly depending on the type of file being transfered
    (some compress better than others).  Very rough numbers range from 3500
    cps for plain ASCII text files to a low of 1440 cps or so, for files
    that won't compress any more at all.  Most everything I download is
    "already compressed" .sit, .cpt, .sea, etc...  On these file types,
    modem compression does very little good, and 1500-1600 cps (give or
    take...) is considered "normal".

    Now, these speeds can drop off a little, or even a lot, if you are
    downloading in the background while you are busy in other applica-
    tions--this is perfectly normal.  What should _not_ be happening is
    repeated packet-errors.  Your Mac divvies up its CPU time to all active
    applications, while monitoring the serial port for proper data-flow
    handling.  So long as it isn't distracted too much by higher priority
    interrupts, it'll detect when the serial port buffer is full (because
    your comm program hasn't been given a chance to empty it lately) and
    it'll issue the hardware handshaking signal to tell the modem to pause.
    When the buffer has room again, data transfer is allowed to continue.
    If all is done properly, your comm program will never see a lost or
    incorrect byte (thus, no packet errors), but it will certainly feel the
    overall slow-down due to the shared CPU time with other applications,
    and 1600 cps is enough of a data-flood for this CPU sharing to be felt.
    Faster Macs should do better here.

I've done all of that, anything else to watch out for?

    I got a number of comments back about various INIT's being CPU hogs
    that can cause trouble.  <Specific names were sparse, just general
    comments.  Please don't Email me for a list, I haven't got one.> I'm
    not convinced this would cause data loss as often as it would cause a
    slow down in effective transfer speed, but clearly the possibility for
    both problems exists.  If you're still having trouble, try temporarily
    rebooting with all non-essential INITs disabled to see if that helps.

    This isn't immediately obvious to many, but it makes perfect sense:  If
    process loading on your machine can slow down a file transfer (CPU
    hogging INITs, background downloading with foreground application
    activity, etc.) then it certainly follows that process loading on the
    _host_ you are connected to can also affect that speed.  If you've been
    getting 1600 cps from a given host for months, made no changes to your
    system or transfer procedure, and see an abrupt and significant drop in
    speed...  before you tear your hair out, send a _polite_ note to the
    sysop and ask if he/she is aware of any activity on their end that
    might account for the change.  Be sure to mention the date(s) and
    time(s) of the transfer(s) in question.  If you _have_ made any
    changes, check them out first--sysops work hard enough.

    I've heard from some who are _sure_ they have a proper HH cable and
    that their software has been told to use HH, and they still get a lot
    of packet errors while downloading.  Two thoughts here:  The host MAY
    have it wrong, or your modem may not be initialized properly.

        Flat out, host problems are unlikely.  Most BBS's and commercial
        services wouldn't last long if they weren't set up right.  Exhaust
        possibilities on your end first before complaining.  If you are
        getting clean file transfers from assorted hosts, but one host
        repeatedly forces packet resends, THEN it's time to consider
        contacting that sysop.

        Modem initialization problems are much more likely.  For example...
        Have you told your modem to return the proper response to indicate
        it has a HH connection?  I.E.  instead of "CONNECT 14400", you
        should see "CONNECT 14400/ARQ" when a "reliable" connection is made
        (or "CONNECT 14400/REL" on some modems).  And you may have to tell
        your comm-program what to look for so it knows that such a
        connection has been made ("/ARQ" or "/REL").  On my modem, and
        probably on most, "AT S95=3" enabled this trick.

    A final thought on debugging:  I got some feedback from folks who tried
    each of the tips above, one at a time.  In the computer world this is
    often a blindly accepted debugging procedure, but it doesn't always
    make sense.  If you've got your computer-to-modem speed set too high,
    and you've not got a proper HH cable, fixing either one won't work--you
    need to fix both at the same time.  Here's my suggestion...  if you've
    got perplexing connection troubles, change everything between the
    wall-jack and your finger tips that even smells suspicious.  Then, if
    all works well, start restoring anything you'd like to restore...  one
    at a time.

By the way, to those of you who wonder about file transfers that abort when
you try to launch a big application, or impose some other long pause...  To
me this doesn't necessarily imply a handshaking error, perhaps the computer
you were connected to decided it had waited long enough and simply
timed-out?  Short pauses should certainly be handled without errors, but
the longer you go - the more likely it is that the host gave up.  No?
(Don't discount the DTR discussion above, item 2)

I read one interesting comment from a modem manufacturer...  They noted
that Apple's serial port buffer is painfully small, making the timing on
handshaking a critical and touchy issue.  They noted that as modem speeds
have increased, fortunately so have Mac speeds - thus somewhat
compensating.  Apparently, we slow Mac owners seem to be in the yellow zone
in the war between CPU horsepower and modem data flow.  It doesn't take
much to tip the battle one way or the other.

Sorry for the length of this, but I hope it helps someone else.

   <Mac Classic II, System 7.1, HSU 2.0.1, 4/40+120, Zoom VFX V.32bis>

Dan Hofferth
[e-mail]